1. Field of the Invention
The present invention relates to a confidential communication method that enables safe communication between two points.
2. Description of Related Art
Recently, intermediary attacks, such as phishing, in communication via the Internet are increasingly emerging as threats. Cryptographic communication alone is not sufficient to ensure safety, and therefore effective countermeasures to the intermediary attacks are in demand.
Examples of techniques that ensure safe communication include SSL encryption communication. The SSL encryption communication using an RSA is designed to reduce intermediary attacks. In the SSL encryption communication using the RSA, a server certificate is inspected to verify authenticity of a communication destination.
However, a server certificate is basically inspected visually, and therefore the inspection takes time and effort. In addition, it is difficult to determine whether the server certificate is a fake prepared by an attacker. In order to resolve these problems, HTTP browsers automatically display a warning message when validity of a server certificate is questioned. However, this technique only verifies whether a server certificate has been authenticated by a pre-registered authentication authority, whether there is any problem with the format of a server certificate, such as valid period, a digital signature, and the like. Therefore, this technique would be of no use when an attacker has an authentic server certificate or registers a fake server certificate as an authentic server certificate using a virus and the like.
In order to reinforce the automatic inspection, an EV certificate (a reinforced server certificate) has recently been introduced. However, the EV certificate merely makes attacks slightly more difficult, and does not provide substantial prevention. As described above, there is so far no truly effective prevention of intermediary attacks in cryptographic communication between two points.
A theme herein is prevention of intermediary attacks at least in communication where two points share confidential information, such as a password. Even when the preventive effect is limited to such circumstances, the achievement has great significance.
For example, in Internet communication in which a password is used to identify a user, such as online banking and network camera viewing, users have a certain right to enforce the use of the resources, and therefore such Internet communication is appealing to attackers. In other words, information found in communication involving an indefinite number of communicators is unworthy for attackers to initiate attacks, since the value of such information is low. Therefore, in terms of the degree of damage, the prevention of attacks at least in communication between two points sharing a password has great significance.
When two points confidentially share a password having a cryptographically-safe bit length, safe cryptographic communication can be performed by using the password as a common key. However, it is difficult for general users to memorize such a password.
Therefore, a technique that prevents intermediary attacks with a memorizable password (i.e., confidential information not having a cryptographically-safe bit length) is in demand. Related Art 1 discloses such a technique known as PAKE (Password Authenticated Key-Establishment) (refer to Related Art 1).    [Related Art 1] S. Bellovin and M. Merritt. Encrypted key exchange: Password-based protocols secure against dictionary attacks. In Proc. IEEE Computer Society Symposium on Research in Security and Privacy, 72-84. 1992.Hereinafter, examples of the use of two types of encryptions in combination is explained with reference to FIGS. 16 and 17. It is also explained that the use of one of the two types of encryptions alone is not sufficient. In FIG. 16, authenticity of a server is not verified.Specifically, server authentication is not performed, and client authentication alone is performed. In the client authentication, a password is protected by a direct encryption with a public key. FIG. 16 is a process flowchart of an off-line attack initiated by an intermediary existing between an authentic client and the authentic server. Password M shared between the client and the server in advance is unknown to the intermediary. In FIG. 16, the authentic server generates public key E, public key N, and private key D in advance, which is not shown in the drawing. The authentic server delivers public key E (in reality, public keys E and N, and a description of public key N is omitted hereinafter unless otherwise required) to the authentic client through an SSL negotiation. Private key D (in reality, private key D and public key N, and a description of public key N is also omitted hereinafter unless otherwise required) is kept by the authentic server. The client (1) directly encrypts password M with public key E, and (2) transmits obtained value X (in reality, “ME mod N”, and, as shown in the drawing as “ME”, a description of “mod N” is omitted hereinafter) to the server. The server has private key D with which data encrypted with public key E can be decrypted, so that the server can derive password M by decrypting value X received from the client. Although password M is unknown to the intermediary, the intermediary can intercept and obtain public key E and value X (encrypted password M). After intercepting and obtaining public key E and value X, the intermediary initiates a brute force attack to derive the password that matches value X received from the client, by (4) generating all types of possible passwords M1, M2, . . . (in reality, all numbers 1, 2, . . . are sequentially checked as value M) and by encrypting them with public key E. In other words, the intermediary initiates a brute force attack off-line (an off-line attack). Password M is normally composed of combinations of 6-10 characters including alphanumeric characters, a few symbols such as “@#%”, and the like. One character is selected from approximately 60 alphanumeric characters and a number of symbols, and the information amount of one character is approximately 6 bits. Accordingly, the information amount of password M is theoretically approximately from 36 bits (equivalent to six characters) to 60 bits (equivalent to 10 characters). However, in reality, many users use memorizable passwords, which are vulnerable to dictionary attacks, and the number of character combinations of a password is much less than the theoretical number. In any case, a bit number of the password level does not prevent the brute force attacks described above, and therefore it is not difficult to identify password M. When value X is encrypted with a common key generated through the SSL negotiation between the authentic client and the authentic server before the transmission and reception of value X, the intermediary cannot decrypt encrypted value X, and hence the above-described off-line attacks are prevented. However, when the intermediary, in addition to intercepting data, performs an SSL negotiation with the client by masquerading as the authentic server, or performs an SSL negotiation with the server by masquerading as the authentic client, and then initiates a bucket brigade attack on-line (an on-line attack), the intermediary can decrypt all the encrypted data transmitted and received between the client and the server. Therefore, password M can be easily identified. Unless verifying authenticity of the server (i.e., correctly performing the server authentication) before the client authentication, communication can be easily intercepted by the intermediary with an online attack. Accordingly, the server authentication must be performed before the client authentication. However, encrypting a password with a public key does not allow the server authentication to be performed before the client authentication. As described above, the direct encryption of a password with a public key does not ensure a high level of safety. In FIG. 17, unlike the example in FIG. 16, the server authentication is performed before the client authentication. In the server authentication in FIG. 17, the client generates a random number, and transmits data generated by encrypting the random number with a password to the server. The server then presents the random number to the client. In other words, the password is used as a common key between the client and the server. Similar to FIG. 16, FIG. 17 is a process flowchart indicating when an off-line attack is initiated by an intermediary existing between the client and the server. Similar to the example in FIG. 16, only the client and the server share password M in advance, and password M is unknown to the intermediary. In FIG. 17, the server and the client start an SSL negotiation, and generate common key K. For example, 3DES (hereinafter, referred to as DES as shown in the drawings) is used as a common key cipher. The number of bits thereof is much larger than that of the password so that brute force attacks are prevented. For example, public key N is 1024 bits, and the DES is 168 bits. However, the further computer technology advances, the longer a bit length a brute force attack can crack. Therefore, a bit length has to be determined in response to the present times. The same applies hereinafter. The client (1) randomly generates random number R having a bit length long enough to prevent brute force attacks, such as 1024 bits, and (2) encrypts random number R with password M. (Although random number R is encrypted with password M by multiplication in the drawing, the present invention is not limited to the same. Any common key cryptosystem, such as the DES or AES, may be used. Password M may be used as the common key, or the common key may be newly generated based on the password. The same applies hereinafter.) The client then (3) transmits value Z (encrypted random number R) to the server. Since the server has password M, (4) the server can derive random number R through decryption. Subsequently, the server (5) hashes random number R, and (6) transmits hash value A=Hash (R) to the client. (7) In receiving hash value A from the server, (8) the client generates value B by hashing previously self-generated random number R. The client then (9) verifies whether value B matches hash value A received from the server, and determines whether the server is authentic (server authentication). In reality, both hash value A and hash value B are Hash (R), and therefore these values match. The client (11) transmits to the server value DES (K, R) (10) generated by encrypting previously self-generated random number R with common key K. (When the party in communication with the client is verified to be the authentic server in server authentication, the party in the SSL negotiation with the client is verified to be the authentic server. Therefore, encrypting the data with the common key generated in the SSL negotiation prevents third parties, such as an intermediary and the like, from opening the data transmitted and received between the client and the server. The same applies hereinafter.) The server sharing common key K with the client (12) derives random number R by decrypting value DES (K, R) with common key K. (13) When random number R matches the value derived by decrypting value Z with password M, the client's authenticity is verified. (Client authentication. Herein, the client presents the previously used random number to the server for the client authentication. However, since the server authentication has been finished at this point, the client may encrypt the password, and presents the encrypted password for the client authentication instead of presenting the random number. The same applies hereinafter.) The server notifies the client of completion of the authentication, by which the server and the client start regular SSL encryption communication. The notification of authentication completion is not necessarily required. The intermediary without password M can intercept and obtain value Z generated by encrypting random number R with password M, hash value A, and value DES (K, R). However, the random number transmitted and received between the client and the server is hashed and encrypted, and therefore the password cannot be easily identified through back-calculation. The intermediary then (16) generates all types of possible passwords M1, M2, (in reality, all numbers 1, 2, are sequentially checked as value M); derives R1, R2, . . . through back-calculation of value Z with the possible passwords; generates hash values thereof; and verifies whether any of them matches hash value A by a brute force attack. In other words, the intermediary initiates a brute force attack off-line (an off-line attack). As described above with reference to FIG. 16, password M is only approximately 36-60 bits, which does not prevent brute force attacks. Therefore, it is possible to identify password M. The above-described off-line attacks can be prevented by encrypting both value Z and value A with the common key generated in the SSL negotiation between the authentic client and the authentic server. However, when the intermediary existing between the authentic client and the authentic server, in addition to just intercepting data, performs an SSL negotiation with the client by masquerading as the authentic server, or performs an SSL negotiation with the server by masquerading as the authentic client, and then initiates a bucket brigade attack, the intermediary can decrypt all the encrypted data transmitted and received between the client and the server. Thereby, the intermediary can obtain value Z that is not encrypted and value A. In this case, the intermediary can pass through both the client authentication and the server authentication only by the bucket brigade attack without identifying the password. In other words, on-line attacks are possible in this case. Accordingly, the server authentication is not effective in the above-described authentication method. As described above, the client's encrypting the self-generated random number with the password does not ensure a high level of safety.
The conventional technique requires both the server and the client to perform heavy calculation. Further, in SSL encryption communication, the conventional technique requires another cryptographic processing in addition to the RSA performed herein. For this reason, a server load increases, and therefore requires a larger memory. Furthermore, the conventional technique requires an increased number of negotiation steps between the server and the client, and therefore the negotiation is prolonged.
When the client's CPU processing function is of lesser quality, or the server performs SSL encryption communication with a large number of clients, both the client and the server have a performance drop problem.
The SSL encryption communication using the RSA (asymmetric public key cryptosystem) is most frequently used by general users, has been practically implemented, and has widely spread. Therefore, there is a need for intermediary attack prevention using a password that is suitable to the SSL encryption communication using the RSA and that ensures safety.